Recent advances in coding techniques allow for transporting data of a broadcast/multicast service in multiple streams, e.g. alternative (simulcast) or optional (layered multicast). Such approaches have attracted attention of the Internet community for enabling coarse-grained quality adaptation in multicast communication and several works have built on these, as for example DiffServ (Differentiated Services—see Blake at al., “An Architecture for Differentiated Services”, RFC 2475, 1998, all RFCs and Internet Drafts by the IETF are available at http://www.ietf.org), RSVP (see Braden et al., “Resource ReSerVation Protocol (RSVP)—Version 1 Message Processing Rules”, RFC 2209, 1997), or NSIS (see Hancock, “Next Steps in Signaling: Framework”, Internet Draft (draft-ietf-nsis-fw-05.txt), 2003). However, the architecture of 3 G communication networks, e.g. like that of 3GPP networks, differs from that of the Internet and thus demands different or additional solutions.
The increasing diffusion of bandwidth-intensive multimedia applications to heterogeneous groups of users led to intensive research in the area of multicast rate and congestion control in the Internet. Since the pioneer work of McCanne et al. (see McCanne et al., “Receiver-driven Layered Multicast”, Proceedings of ACM SIGCOMM '96, p. 117 to 130, 1996), multi-rate multicast has been considered as a very promising approach for rate adaptation in streaming scenarios. Techniques have been proposed for transmitting the same content using multiple multicast groups mapping onto different quality levels, based on a cumulative layered data organization (hierarchically encoded) or on stream replication (independent and alternative streams). Moreover, a combination of both approaches is also possible. For example, a session of a single audio stream and several alternative video streams encoded with a standard coding scheme at different data rates or robust to different loss rates could be considered.
Generally, the Internet Multicast Model provides basic mechanisms for distributing data with different QoS parameters to subsets of the multicast distribution trees. The hosts, which communicate with the multicast routers using the Internet Group Management Protocol (IGMP—see Fenner, “Internet Group Management Protocol, Version 2”, RFC 2236, available at http://www.ietf.org), can in principle actively adapt the QoS in a sub tree by joining/leaving multicast groups.
However, not all communication networks, e.g. mobile communications networks, follow Internet's end-to-end paradigm. In this regard, compliance to the end-to-end principle means that end hosts are responsible for adaptation to network conditions, relying exclusively on implicit network signaling, i.e., packet drops and delay variations.
Mobile communications networks, on the other hand, usually follow a network-centric approach for QoS provision, resulting in a different Broadcast/Multicast Service Model. Subscribed users are allowed to express their interest on a multicast session by IGMP or similar signaling to dedicated network nodes. The data distribution tree along which service data are provided, however, is build autonomously and modified by the network when necessary, e.g. in response to handover. This approach is advantageous in particular since the radio network controller has the knowledge of available resources (e.g. by providing resource control functionality), and it allows end users to be provided with a more or less seamless service.
Several network-centric approaches for providing heterogeneous communication services in the Internet have also been proposed. A well-known way to implement enhanced functionality within the network is the establishment of transport-level or application-level gateways, or the introduction of active network nodes, as presented in Amir et al. “An application level video gateway”, Proceeding of ACM Multimedia '95, SanFrancisco, Calif., USA, November 1995 or in Metzler et al., “AMnet: Heterogeneous Multicast Services based on Active Networking”, Proceedings of the 2nd Workshop on Open Architectures and Network Programming (OPENARCH99), New York, N.Y., USA, March 1999, respectively.
While the former approach imposes significant overhead due to transcoding operations, the latter approach provides a framework that needs to be adapted in each case to provide network-specific functionalities and mechanisms.
The first concept for a heterogeneous QoS in the MBMS Architecture was proposed as Option G in the 3GPP TR 23.846: “Multimedia BroadcastlMulticast (MBMS); Architecture and functional description (Release 6)”, V6.1.0, December 2002, available at http://www.3gpp.org (for an overview on the architecture and functional description of MBMS see 3GPP TS 23.246: “Multimedia Broadcast/Multicast (MBMS); Architecture and functional description (Release 6)”, V6.2.0, March 2004). The architecture in TR 23.846 defines a MBMS Bearer Service that may include multiple streams (optional or alternative), each mapping to a single RTP instance. Each stream is transported over a unique tunnel between GGSN (Gateway GPRS Support Node) and RNC (Radio Network Controller), which is maintained throughout the duration of a MBMS service.
Thereby, it is in principle possible for a RNC to choose a stream of a MBMS service at session start as well as changing/adding streams during the session. However, in order to allow for this functionality, appropriate mechanisms have to be implemented in the radio access network (RAN). A necessary prerequisite is the communication and management of stream states and relations, which allows a RAN node to choose the (set of) appropriate streams according to the current conditions of a cell or downstream nodes
The 3GPP Multimedia BroadcastlMulticast Service (MBMS) Architecture currently only supports a very simple QoS model. It basically provides a non-scalable and non-adaptive service, where either all branches of a MBMS distribution tree are established with the same QoS or the whole service is cancelled. There is no negotiation of QoS values between network nodes, which implies that some of the branches may not be established if QoS requirements cannot be met by the according network nodes. This is relevant both at the beginning of a session or during a session, e.g. at each handover, when a new branch of the distribution tree has to be created/torn down.
On the other hand, mobile terminals are quite heterogeneous with respect to their provided capabilities, i.e., processing power, display size, etc. The current MBMS architecture cannot cope with this heterogeneity or it can by subjecting all terminals (those with better and worse capacity) to a worst case scenario, where all adapt to the lowest quality.
The MBMS Architecture is, however, not optimal in view of accounting and service provision. For example, in case a single user service consisting of a plurality of alternative streams (for example, three different audio streams at different bit rates) or complementary streams (for example, three video streams at different bit rates and two audio stream at different bitrates) is provided using the 3GPP MBMS architecture, each of the alternative streams would need to be provided as three separate MBMS services, each comprising one of the alternative streams.
Likely, considering the provision of complementary streams, there are six different combinations of streams possible. Again, the MBMS architecture would require that each possible combination of streams is provided as a separate MBMS user service to the users. Also in case layered streams are transported, same would be provided in a respective MBMS User Service per layer combination. I.e. for example, when the service media is provided in three layers (base, enhancement 1, enhancement 2) there would need to be established three different MBMS services (base, base & enhancement 1, base & enhancement 1 & enhancement 2).
As indicated above, the lack of an adequate QoS model in MBMS and the implications from the MBMS architecture do not allow for QoS differentiation in individual branches of the distribution tree of a service. Further, the need for several parallel MBMS services required for providing alternative or complementary streams of an, actually, “single” service leads to an increased signaling overhead in the network and wastes resources in the UMTS network.
The establishment of a conventional MBMS service using the conventional MBMS architecture will be explained in the following with reference to FIG. 4. The UE receives 402 an MBMS User Service description in a service discovery or announcement procedure 401. This MBMS User Service description describes all MBMS bearers contained in the MBMS User Service. The individual bearers are identified by their respective TMGI (Temporary Mobile Group Identifier), which is dynamically allocated in the BM-SC (Broadcast/Multicast Service Center).
An exemplary MBMS User Service description is shown below:
<?xml version=“1.0” encoding=“UTF-8”?><userServiceDescriptionxmlns=“www.example.com/3gppUserServiceDescription”xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”serviceId=“urn:3gpp:1234567890coolcat”><deliveryMethod sessionDescriptionURI=“http://www.example.com/3gpp/mbms/session1.sdp”/><deliveryMethod sessionDescriptionURI=“http://www.example.com/3gpp/mbms/session2.sdp”/></userServiceDescription>
According to this example, the MBMS User Service description refers to two session descriptions session1.sdp and session2.sdp, which both define a bearer belonging to the MBMS service requested by the user.
Next, the UE activates 403 all MBMS bearers contained in the MBMS User Service Description. It is to be noted that the activation of a bearer is to be understood as setting of a logical state in the distribution tree of the MBMS service to indicate that the respective UE requests the service. The activation of the bearers does not imply the reservation of resources in the network.
As soon as the BM-SC is ready to start the User Service, it sends 404 a MBMS Session Start Request for each bearer of the User Service to the network. In response to the session start procedure, the RNCs send 405 MBMS notifications over the air to inform the UEs of upcoming data transmission. The radio bearer information necessary for the reception of the bearers is included in these notifications. The TMGI is used to identify the respective MBMS bearer. Upon sending the notifications, the RNC allocates the radio resource required for service provision. Based on the information received in the notifications, the UEs may tune in to receive the data which are provided 406, 407 from the BM-SC via the CN/RAN to the UE.
In the 3GPP MBMS architecture, the UEs will activate all bearers (carrying one or more of the individual streams of the service) and will expect that a notification for each bearer is received and that data is provided on each of the bearers belonging to the MBMS User Service. Assuming that a single MBMS service in an enhanced MBMS architecture allows providing a plurality of bearers transporting layered, alternative, or complementary streams within a single user service, it is clear that not all of the bearers listed in the MBMS User Service description need to be simultaneously provided to the UEs.
However, if the UEs do not receive all bearers listed in the 3GPP MBMS User Service description, the UEs will consider this an error in service delivery and will act accordingly.